1. Technical Field
The present invention relates to a server apparatus, a client apparatus and a network system which can easily protect access to content.
2. Background Art
In order to enable detection and control of devices connected to network, a protocol called Universal Plug and Play (UPnP) is standardized (for example, refer to a non-patent literature, “Universal Plug and Play Device Architecture Version 1.0”, [online], Jul. 8, 2000, UPnP Forum, [search date: Mar. 25, 2000].
UPnP uses standard Transmission Control Protocol/Internet Protocol (TCP/IP) and Internet Protocol, and realizes functions such as acquiring information on the existence and functions of other devices, and notifying the self-owned functions. Thus, setup, setting and addition of peripheral devices can be easily executed.
The basic components of the UPnP network are a device, a service and a control point. The UPnP device is a device which holds a service that is the smallest unit for control. For example, a VTR device includes a tape transport service, a tuner service and a clock service. The control point is a controller which can detect and control other devices.
The UPnP device which is newly connected to network acquires an IP address for joining the network. The acquisition of the IP address is executed by a Dynamic Host Configuration Protocol (DHCP) server automatically assigning an address to a DHCP client held by each device.
When a new device is assigned with an IP address, and can communicate, the new device (i) multicast-transmit (UDP: User Datagram Protocol) Generic Event Notification Architecture (GENA) advertise of each device and service, and (ii) announces the existence thereof (Alive transmission). Also, the new device transmits a detection message which advertises a service. Here, the advertise needs are to be retransmitted before expiration. In addition, the device transmits a message regarding explicit exit before the device goes off-line.
The control point on network is capable of (i) multicasting a Simple Service Discover Protocol (SSDP) detection message, and (ii) searching a related device and service (M-Search). Using the above mentioned technique, for example, in the case where the control point is a video control application, (i) a device which is a server of Audio and Visual (AV) content can be searched, (ii) all of the video devices on network can be displayed, and (iii) the video device which is the server of the desired content can be selected.
FIG. 6 is a configuration diagram showing a conventional network system. As shown in FIG. 6, the network system comprises: a server 31 which is a device including a server function; a client 32; and a network 3. The client 32 includes a control point function and a renderer function which displays a reception decode.
A CPU 301 executes a process for managing a device connected to the network 3 according to the management program. An ROM 105 holds a start-up program for starting up the server 31. After the start-up, the server 31 executes predetermined processes such as the above mentioned DHCP and Alive transmission.
In the client 32, a CPU 201 (i) causes a Graphical User Interface (GUI) controller 210 and a user operation Interface (IF) 211 to display a menu screen, “device selection”, and (ii) causes a message communication unit 212 to transmit, via a communication IF 207, an M-Search message which searches a server for a device on the network 3.
The M-search message has an SSDP request format using Hypertext Transport Protocol Multicast (HTTPMU) which uses Hypertext Transport Protocol (HTTP) on the UDP. Here, as the search criteria, “Media Server” service defined by UPnP forum is included (for example, refer to the non-patent literature, “Media Server: 1 Device Template Version 1.0”, [online], Jun. 25, 2002, PnP forum, [search date: Mar. 25, 2000]. The device which received the M-Search message (i) listens to the standard multicast address of the message, and (ii) responses whether or not the service held by the device corresponds with the search criteria of the detection message.
In the ROM 105 of the server 31, “Media Server” is memorized as device information. A search information judgment unit 106 of the server 31 compares the device information of the ROM 105 with the content of the M-search message received via a communication IF 307 and a message communication unit 312. As a result of the comparison, if the search information judgment unit 106 confirms that the device information corresponding with the M-Search content exists, the search information judgment unit 106 notifies the fact to the message communication unit 312. Then, the message communication unit 312 generates a message indicating the above mentioned correspondence with the search conditions, and responds to the client 32 via the communication IF 307. The response to the search request is transmitted, using the unicast UDP attached with the SSDP header, to the IP address of the client 32 which started the search.
The response to the search request includes a Uniform Resource Locator (URL) which can acquire Device Description. In the client 32, in order to acquire the Device Description of the UPnP, a device information acquisition unit 208 which received the response via the communication IF 207 and message communication unit 212 causes the message communication unit 212 to (i) generate an HTTP GET request regarding the URL included In the response message, and (ii) issue the HTTP GET request via the communication IF 207. In response to the HTTP GET request received via the communication IF 307, the message communication unit 312 of the server 31 (i) acquires, via the search information judgment unit 106, the Device Description information included in the ROM 105, and (ii) returns the Device Description information to the client 32 via the communication IF unit 307.
The Device Description Information lists, in eXtensible Makeup Language (XML) format, properties related to the device such as information regarding a service set provided by the device type, the device model name, the model number, the manufacturer name, the description information regarding the product, the serial number, the Friendly Name (device name), and the icon.
The device information acquisition unit 208 of the client 32 (i) receives the Device Description information via the communication IF 207 and message communication unit 212, and (ii) requests the CPU 201 to analyze the information. Then, the CPU 201 analyzes the list of the XML format, and acquires information such as the device model name and Friendly Name. The CPU 201, using the acquired information, causes the GUI controller 210 and user operation IF 211 to sequentially display, on the monitor, the list of the devices corresponding with the search conditions, that are here, the Media Server devices. An example of the display screen is shown in FIG. 7.
The pointer (URL) to the Service Description is included in the Device Description information. And, the Service Description can be acquired as well as the Device Description by HTTP GET request to the URL. FIG. 7 is an XML document including a list of all services such as veranda-specific information, definition of embedded device, URL of device presentation, and URL of control and eventing. Thus, by accessing the control URL of the Device Description of the device (here, the server 31) selected from the control point of the client 32, the device can be controlled. The access is executed using the Simple Object Access Protocol (SOAP).
The control point of the client 32, using the control, after acquiring information of Content Directory Service (CDS) for notifying the content list held by the device, by accessing the URL described therein, acquires data stream of AV content. When the CPU 201 of the client 32 instructs the message communication unit 212 to access the URL of the server 31, the message communication unit 212, according to the instruction, (i) generates a message requesting to acquire data using HTTP GET, and (ii) causes the communication IF 201 to transmit the generated message to the predetermined port of the communication IF 307. The server 31, according to the request, while adjusting transmission timing, rate and the like using the data output management unit 303, outputs the data included in the content data record reproduction unit 302, via the communication IF 307. The client 32, while adjusting the request using a data input management unit 203 so that the decoder 202 can process the request, (i) receives the data stream from the communication IF 207, and (ii) executes reproduction using the decoder 202.
Also, if the client 32 registers URL (registering of eventing) in eventSubURL of the Device Description included in the server 31, when the state of the server 31 is changed, the change can be notified to the above mentioned URL (URL of CALLBACK header) registered by the client 32. For example, when the content list information changes, on the server 31 side, due to content removal, name change, new addition caused by recording, the change can be notified to the client 32.
Here, the server device which is connected to network and holds AV content needs to deal with the threat from the network. Specifically, the following threats are assumed: intrusion from Internet into a recorder; intrusion from a fragile radio Local Area Network (LAN) into a recorder; family's intrusion from an in-home network into an individual specific recorder; blocking of user's communication by an unauthorized request transmitted from Internet; and the like.
As countermeasures against the above mentioned threats, access limit such as (i) authenticating, when accessing, the information which is not desired to be open to the third party, and (ii) rejecting access from Internet is necessary for a consumer AV device connected to network in the future.
However, unlike a Personal Computer (PC) and the like, a consumer AV device has a poor input system. And, it causes a large burden to force the user to input the password for every access on the side of the client device. Also, a method for registering, in advance, the client devices (control points) for which access is permitted on the side of the server device is conceivable. However, in such case as described above, there are a large number of characters to be inputted, and this is a large burden for the user.
As an improvement measure for the above mentioned problem, a method for (i) displaying the list of the client devices which may access from the server, and (ii) selecting and registering the client devices for which access is permitted is conceivable. However, according to the UPnP, as described above, the responses to the advertise and search are defined for the device on the side to be controlled. On the other hand, the client device side needs not to be discovered by the server device in the regular use, and does not have the defined responses to the advertise and search as described above. Therefore, there is a problem that the client devices (control points existing on network) which may access cannot be confirmed on the side of the server device.